Java Distributed Separate Objects

Java supports distributed programming using threads and Remote Method Invocation (JRMI). However, a Java thread does not match well with the object concept, and JRMI cannot easily used to synchronize distributed objects. This work proposes a more object oriented model for concurrent and distributed programming using the notion of separate objects. Separate objects are asynchronous objects maybe running on different processors. These objects are also used for synchronization. The presented approach should encourage more seamless designs. The implementation is supported by JOODE (Java Object Oriented Development Environment) which supports the use of an adaptable platform of a net of processors. 1 IS CONCURRENCY IN JAVA TRULY OBJECT-ORIENTED? To obtain asynchronous behavior of an action, a Java programmer must extend the class Thread, encapsulating the action in the run method. The classic production-consumption example can be illustrated with the following pattern. A class Producer extends Thread and encapsulates the production algorithm in its overridden run method, and a class Consumer, also extending Thread, encapsulates the consumption algorithm. Both, the production and consumption threads, will synchronize using a buffer. To initiate the production-consumption behavior a method must create instances of Producer and Consumer and “activate” both instances by calling their corresponding start methods (Listing 1). class Producer extends Thread { private Buffer buf; public void produce(){ ..produces an object and puts it in the buffer.. } ... public void run(){ while (some condition) { produce(); } } } JAVA DISTRIBUTED SEPARATE OBJECTS 120 JOURNAL OF OBJECT TECHNOLOGY VOL. 1, NO. 2 class Consumer extends Thread { private Buffer buf; public void consume(){ ..consumes an object from the buffer.. } ... public void run(){ while (some condition) {consume();} } } class Main { public static void main(string[] args){ Buffer b = new Buffer(); Producer p = new Producer(b); Consumer c = new Consumer(b); /* do the production consumption in an asynchronous way */ p.start(); c.start(); ..do other actions.. } LISTING 1 Production consumption using threads Supposing that the production process has two alternating production algorithms, the Producer class should be reprogrammed (Listing 2). class Producer extends Thread { private Buffer buf; public void produce1(){..one algorithm..} public void produce2(){..other algorithm ..} ... public void run(){ while (some condition) { produce1(); produce2();} } } LISTING 2 Two alternating production algorithms But what if the production process changes again and we want two executions of the method produce1 for each execution of produce2? The class Producer must be reprogrammed (or extended) changing (or overriding) the run method (Listing 3). class Producer extends Thread { private Buffer buf; public void produce1(){ ...one algorithm of production..} public void produce2(){ ..other algorithm of production..} ... Is Concurrency in Java Truly Object-Oriented? VOL. 1, NO. 2 JOURNAL OF OBJECT TECHNOLOGY 121 public void run(){ while (some condition) { produce1(); produce1(); produce2();} } } LISTING 3 Another production approach The above approach is not particularly object oriented and does not enforce reusability because changes must be made in the Producer class and not in the class requiring the new production process. The only behavior that Producer should encapsulate is the two production algorithms, but how these algorithms should alternate in a production process should not be Producer's responsibility. A cook (the producer) knows to prepare various recipes. He works concurrently with a waiter. But it is the waiter who knows the sequence of the client's requests. The waiter sequentially requests the cook for menu items while she/he should continues serving clients. The cook's routine must not change because the waiter's has changed. Another solution could be to have two classes Producer1 and Producer2, one for each production method, and then create objects p11 and p12 of type Producer1 and p2 of type Producer2. The production strategy can now be placed in the client code (Listing 4). But it is like having a cook for each recipe (a non too much efficient restaurant). class Producer1 extends Thread { private Buffer buf; public void produce(){..production algorithm 1..} ... public void run(){produce();} } class Producer2 extends Thread { private Buffer buf; public void produce(){..production algorithm 2..} ... public void run(){produce();} } class Main { public static void main(string[] args){ Buffer b = new Buffer(); Consumer c = new Consumer(Buffer b); c.start(); Producer1 p11 = new Producer1(b); Producer1 p12 = new Producer1(b); Producer2 p2 = new Producer2(b); while (some condition){ p11.start(); JAVA DISTRIBUTED SEPARATE OBJECTS 122 JOURNAL OF OBJECT TECHNOLOGY VOL. 1, NO. 2 p12.start(); p2.start(); ..do other actions.. } LISTING 4 Production objects with different threads This solution looks more object-oriented than the previous but it hides some drawbacks. Observe that when running Listing 4, the behavior may not be as intended. The three different threads were started in the order p11, p12 and p2 but this does not mean that the result of their production will be in this order in the buffer. This depends on the duration of each production method and on the time slicing scheduling mechanism of the threads in the JVM. Another drawback of this approach is the proliferation of classes. The original class Producer (Listing 2), having the two methods produce1 and produce2, has been split into two classes (Producer1 and Producer2), one for each production method. Nevertheless, in the original design, both production methods could share commonly defined information in their class. Such commonality could not be easily expressed in the new approach because there are two different classes with a single production method in each one. Where could this "common" information be located? A Java fan could argue that the Java thread and the synchronized specifier are sufficient to model every concurrent behavior. But in opposition to object-oriented goals, the price to be paid could be derived in a clever design and low maintainability with little adaptability to a distributed environment. This paper attempts to offer a more objectoriented and expressive approach which serves as a foundation to the development of Java concurrent and distributed applications.